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(57) Abstract: The invention relates to a mobile telephone device consisting of (i) a storage device (1) (e.g. SIM/USIM card) 
comprising means of storing at least one application (3 A, 4A) and (ii) at least one module which is used to manage arrays (5) of data 
from at least one application stored in said storage device. Moreover, the aforementioned module comprises means of receiving, via 
a remote access message (OTA), at least one instruction relating to an operation concerning a datum contained in an array from a 
C4 specified application, means of accessing the array according to the instruction and means of performing at least one operation in 
relation to said at least one datum in the array in accordance with the instruction. The invention also relates to a method of managing 
data in arrays from applications stored in a card belonging to a piece of mobile telephone user equipment. 
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(57) Resumen: Un dispositive de telefonia mdvil, que comprende: un dispositivo de almacenaje (1) (por ejemplo, una tarjeta 
SIMAJSIM) que comprende medios para almacenar, al menos, una aplicaci6n (3A, 4A); al menos un m6dulo gestor de arrays (5) de 
datos de, al menos, una aplicaci6n almacenada en el dispositivo de almacenaje, que comprende medios de recibir, mediante un men- 
saje de acceso remoto (OTA), al menos una instruccidn de operaci6n sobre al menos un dato contenido en un array de una aplicaci6n 
especificada, medios de acceder a dicho array en funci<3n de dicha instrucci6n, y medios de realizar al menos una operaci6n sobre 
dicho al menos un dato en dicho array, en funci6n de dicha instrucci6n. La invenci6n tambi^n se refiere a un m^todo de gestidn de 
datos en arrays de aplicaciones almacenadas en una taijeta de un equipo de usuario de telefonfa m6vil. 



wo 2004/014093 




:T/£S2003/000400 



UN DISPOSITIVO DE TELEFONIA M6VIL Y UN M^TODO DE GESTI6N DE DATOS 

CAMPO DE LA INVENCI6N 
La invenci6n se engloba en el campo de la telefonfa m6vil. Como es sabido, en 
5 dicho campo, normalmente se utilizan acrbnimos y t^rminos anglosajones para 
referirse a elementos y conceptos propios del campo. Para facilitar la lecture de esta 
memoria descriptive para un lector no experto en la materia, se expone a continuacidn 
un listado de acr6nimos utilizadas en la presenter 



GSM Global System for Mobile Communication 

10 ICC Integrated Circuit Card ("Tarjeta Chip") 

SIM Subscriber Identity Module ("M6dulo de Identificaci6n de Usuario"). 

SAT SIM Application Toolkit ("Aplicaciones SIM Toolkit" o. simplemente, 

"Aplicaciones Toolkit"; conjunto de herramientas para aplicaciones sobre 

la SIM) 

15 UMTS Universal Mobile Telecommunications System (tambi^n llamado 

"Tercera Generaci6n de Telefonia M6vil") 
UlCC UMTS Integrated Circuit Card (la "tarjeta chip" para el UMTS) 

USIM Universal Subscriber Identity Module (el M6dulo de Identificacion de 

Usuario en el UMTS) 
20 USAT USIM Application Toolkit (el SAT en el caso del UMTS) 

OTA Over The Air (Acceso remote a la tarjeta SIM/USIM) 



ANTECEDENTES DE LA INVENCI6N 
Actualmente existen diferentes tipos de tel6fonos m6viles (tambi6n llamados 
25 "tel6fonos portStiles" o "celulares"), que suelen estar dotados de un teclado y de una 
pantalla con capacidad para mostrar simbolos alfanum^ricos y, en muchos casos, 
tambi6n gr^ficos. 

Actualmente existen varios sistemas de telefonia m6vil, entre ellos el sistema 
GSM y el UMTS (tambi6n llamado la "Tercera Generaci6n de Telefonia Mbvil"). 
30 El equipo de usuario comprende, tanto en el sistema GSM como en el sistema 

UMTS: 

a) por una parte un terminal (que es el que muchas veces se denomina 
"tel6fono m6vil") (que incluye una carcasa. pantalla, teclado, fuente de alimentaci6n y 
circuitos diversos); y 

35 b) por otra parte una tarjeta ICC o UlCC (UMTS Integrated Circuit Card). 
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En el caso de GSM se trata de una tarjeta ICC llamada tarjeta SIM o simplemente SIM 
(Subscriber Identity Module) o de una UlCC con una aplicacion SIM y en el caso de 
UMTS se tratara de una UlCC con una aplicacion USIM. Tanto la tarjeta SIM como la 
tarjeta UlCC (con una o varias aplicaciones SIM y/o USIM) contienen un conjunto de 
5 ficheros con datos del operador de la red de telefoni'a m6vil y del usuario (subscriber) y 
estSn dotadas de medios de ejecutar operaciones asociadas a una serie de comandos 
que permiten al terminal acceder a esos ficheros (leerlos. escribirlos, seleccionarlos, 
verificar claves de usuario, etc.). Entre los datos de usuario est^n los que autentifican. 
al usuario ante la red. 

10 Hasta la llegada de UMTS (la llamada Tercera Generaci6n de Telefonia Movil) 

no se soHa hacer distincibn alguna entre el interfaz fi'sico de la aplicacion (dependiente 
de la propia naturaleza de la tarjeta inteligente ICC) y la propia aplicacion: ambos eran 
llamados SIM. La tercera generaci6n de telefonia m6vil (UMTS) introdujo la separacion 
del interfaz ffsico y las aplicaciones. El interfaz fisico recibe el nombre de UlCC; se 

15 trata de una plataforma en la que pueden convivir varias aplicaciones 
simult^neamente; entre ellas puede haber aplicaciones SIM y/o USIM. La aplicacibn 
de identificacion de usuario propiamente dicha recibe en UMTS el nombre de USIM. 

Se considera que una tarjeta inteligente es un dispositive fisicamente seguro, 
es decir, es un dispositivo en el que los datos almacenados se encuentran protegidos 

20 frente a ataques de terceros que pretendan leerlos, modificarlos, borrarlos o falsearlos 
sin permiso del propietario de la informacibn. 

A continuaci6n, en ocasiones nos referimos al mbdulo de identificacion de 
usuario como SIM tanto para GSM como para UMTS (es decir, con SIM tambi6n nos 
referimos a una UlCC con las aplicaciones SIM o USIM correspondientes). 

25 En el campo de la telefonia m6vil tambien se conoce el concepto SAT=SIM 

Application Toolkit (en UMTS, USAT=USIM Application Toolkit), que conslste en un 
conjunto de herramientas para aplicaciones sobre la SIM; a contlnuaci6n. nos 
referimos a una aplicacibn basada en dichas herramientas como una "aplicacidn 
Toolkit". 

30 En un primer momento, los terminales mbviles s6lo eran capaces de enviar 

comandos a las SIMs, mientras que las SIMs solo eran capaces de responder a 
comandos recibidos desde el terminal m6vil. 

Posteriormente se produjo una evolucibn de los terminales m6viles y de las 
tarjetas SIM y se permite. por un lado, a los terminales tanto enviar comandos a la 

35 tarjeta SIM como recibir comandos de la misma, y por otro lado, a la tarjeta SIM tanto 
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responder a comandos recibidos desde el terminal movil cx>mo enviar comandos al 
mismo. Estos comandos pemiiten a la SIM, por ejempio, solicitar al temiinai el envfo 
de un mensaje cx)rto (SM), la realizacion de una llamada, mostrar una lista de opclones 
al usuario, solicitarle un dato, etc. 
5 Las aplicaciones existentes en la tarjeta SIM capaces de enviar comandos al 

terminal m6vil se conocen con el nombre de aplicaciones SAT (SIM Application 
Toolkit). En UMTS se conocen con el nombre de aplicaciones USAT (USIM Application 
Toolkit). En general, tanto a unas como a otras se las llama aplicaciones Toolkit. 

Las aplicaciones Toolkit son una caracteristica opcional tanto de las tarjetas 
10 SIM como de las tarjetas UlCC (con las aplicaciones correspondientes). Los 
procedimientos de alto nivel, contenidos y codificacion de los comandos. est^n 
especificados en la norma GSM11.14 para GSM y en la norma 3GPP TS 31.111 para 
UMTS. 

Tambi6n se conoce el concepto OTA (Over The Air), que se refiere al acceso 
15 remote a la tarjeta SIM (o USIM). Inicialmente, cuando las tarjetas salian al mercado, 
el operador no podia modificar nada en ellas, estaban fuera de su alcance. Sin 
embargo, parecia interesante poder modificar el contenido de algunos ficheros en la 
tarjeta, modificar el perfil de personalizaci6n y cargar o modificar aplicaciones Toolkit 
una vez que la tarjeta estaba en posesi6n del cliente. 
20 Por tanto, los fabricantes de tarjetas empezaron a incorporar sistemas OTA (de 

acceso remoto) que permitian gestionar los contenidos de la tarjeta mediante 
mensajes corlos especiales. Cada fabricante disponia de una solucibn propietaria 
incompatible con las de otros fabricantes. Posteriormente se han generado unas 
especificaciones est^indar para realizar este tipo de modificaciones remotas OTA 
25 (GSM 03.48 y 3GPP 23.048). Bas^ndose en estas especificaciones se pueden 
implementar sistemas OTA compatibles que permiten la gestion de ficheros y de 
aplicaciones. 

En la actualidad se est^ trabajando en la definici6n de est^ndares que permitan 
emplear otros tipos de portadoras, no solo mensajes cortos, para hacer 
30 comunicaciones mds r^pidas y flexibles, estas portadoras pueden ser GPRS (General 
Packet Radio Service), Bluetooth, llamada de datos, etc. 

En telefonia movil se est^n desarrollando multitud de aplicaciones SIM Toolkit 
que se pretenden gestionar por el operador de forma remota. El problema surge 
cuando se quiere acceder remotamente a datos de la aplicaci6n como pueden ser los 
35 textos que muestra. numeros de telefono a los que llama o manda mensajes cortos o 
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cualquier otro tipo de datos. 

Las aplicaciones pueden ser cargadas de forma remota siguiendo los 
estdndares, pero no est& definida la creaci6n de ficheros de forma remota. por tanto, si 
se quiere que una aplicaci6n se pueda cargar y que contenga algOn tipo de dato, el 
5 dato se debe almacenar en un array y no en un fichero para que se pueda descargar 
en la tarjeta de forma remota. El problema se encuentra en que no estd definido de 
ninguna forma el acceso remoto (es decir, "vfa OTA") a los datos almacenados en 
arrays. 

Por tanto, si se quieren cargar aplicaciones de forma remota, los datos se 
10 deben guardar en arrays y no en ficheros, pero los arrays ho son modificables de 
forma remota, por lo que los datos de una aplicaci6n cargada remotamente no podrfan 
modificarse remotamente. Actualmente para modificar uno de estos datos se debe 
borrar la aplicacion y volver a cargaria entera con el dato modificado. perdiendo toda la 
informaci6n que pudiese haber introducido el usuario para personalizar la aplicacidn. 
15 El hecho de tener que eliminar y volver a cargar la aplicaci6n para modificar, 

por ejempio, un numero de tel6fono hace necesario el envi'o de entre 40 a 60 
mensajes cortos para una aplicacidn tipica (depende del tamano de la aplicacibn) 
cuando si el numero de tel^fono a modificar estuviese en un fichero bastarfa con un 
mensaje corto, 

20 La figura 1 ilustra un ejempio del estado de la t^cnica: una tarjeta SIM (o 

USIM) 1 contiene un gestor de acceso remoto (gestor OTA) 2 que comprende un 
modulo gestor remoto de aplicaciones 2A y un m6dulo gestor remoto de ficheros 2F. 
La tarjeta 1 incluye, adem^is, una primera aplicacibn Toolkit 3A y una segunda 
aplicacibn Toolkit 4A. Las aplicaciones pueden ser aplicaciones SAT o USAT. La 

25 primera aplicacion Toolkit 3A estd relacionada con (lee, escribe, manipula. etc.) datos 
3D que se almacenan en un fichero 3F. Dicho fichero se establece durante la 
personaltzacibn de la tarjeta en la fabrica (flecha "a" en la figura 1). La segunda 
aplicacibn Toolkit 4A est6 relacionada con datos 4D almacenados en un array que 
forma parte de la propia aplicacion. 

30 La tarjeta 1 puede ser gestionada de forma remota mediante un sistema OTA; 

los mensajes OTA se reciben en el equipo de usuario y se transmiten a la tarjeta, en la 
que el gestor de acceso remoto 2 (que en si constituye una aplicacibn Toolkit) se hace 
cargo de realizar las operaciones oportunas. Mediante el mddulo gestor remoto de 
aplicaciones 2A se pueden cargar en la tarjeta las aplicaciones 3A (flecha "b") y 4A 

35 (flecha "c") y, si el fichero 3F ha sido establecido en la fabrica durante la 
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personalizaci6n de la tarjeta, los datos 3D se pueden escribir, leer o manipular de 
forma remota (OTA) mediante el mbdulo gestor de ficheros (2F) (flecha "d"). (Sin 
embargo, si el fichero 3P no se ha creado durante la mencionada personallzacidn en la 
fdbrica, no serd posible cargar correctamente la primera aplicaci6n Toolkit 3A, ya que 
5 no se puede crear el fichero asociado 3F de forma remota (OTA)). 

Por otra parte, en cuanto a la segunda aplicaci6n Toolkit 4A, el sistema actual 
de acceso remoto (OTA) permite cargar la aplicacidn de forma correcta a pesar de que 
no tiene fichero asociado, ya que la aplicacibn no requiere fichero: como hemos 
indicado. los datos 4D estdn alojados en un array en la propia aplicacidn. Sin embargo, 

10 el actual sistema de acceso remoto (OTA) a la tarjeta no permite modificar los datos 
4D asociados a dicha aplicacidn de forma remota. ya que el sistema de acceso remoto 
(incluyendo el gestor de acceso remoto 2) no comprende medios de acceso y 
manipulacibn de datos en un array de una aplicacidn. Por tanto. para modificar 
cualquier dato 4D serfa necesario borrar toda la aplicacidn 4A y volverla a cargar a 

15 traves del mddulo gestor de aplicaciones 2A, con los inconvenientes que ello implica. 

DESCRIPCI6N DE LA INVENCI6N 
Un primer aspecto de la invencidn se refiere a un dispositive de telefonfa mdvil 
(que puede ser una tarjeta SIM/USIM o un equipo de usuario que comprende un 
20 terminal y dicha tarjeta SIM/USIM), que comprende: 

un dispositive de almacenaje (por ejempio, una tarjeta chip (ICC) con un 
mddulo de identificacidn de usuario (SIM/USIM)) que comprende medios para 
almacenar. al menos, una aplicacidn (por ejempio, una aplicacidn SAT/USAT); y 

medios de gestidn por acceso remoto (OTA) del dispositivo de almacenaje en 
25 base a recepcidn de mensajes de acceso remoto (OTA) por telefonfa mdvil (es decir, 
los medios comentados en lo anterior, incluyendo. por ejempio, un gestor de acceso 
remoto -gestor OTA- con su gestor de aplicaciones y gestor de ficheros y las diferentes 
portadoras que pueden emplearse para hacer llegar los mensajes de acceso remoto a 
la tarjeta como pueden ser mensajes cortos. Ilamadas de datos, GPRS, Bluetooth, 
30 etc.). 

Segun la invencidn. el dispositivo comprende ademds. al menos, un mddulo 
gestor de arrays de datos de, al menos, una aplicacidn almacenada en el dispositivo 
de almacenaje. El mddulo gestor de arrays de datos comprende: 

- medios de recibir, mediante un mensaje de acceso remoto (OTA), al menos 
35 una instruccidn de operacidn sobre al menos un dato contenido en un array de una 
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aplicacibn especificada; 

- medios de acceder a dicho array en funcion de dicha instruccibn; y 

- medios de realizar. al menos, una operacibn sobre dicho a! menos un dato en 
dicho array, en funci6n de dicha instruccibn. 

5 El m6dulo gestor de arrays de datos es el encargado de procesar los datos o 

instrucciones recibidos en un mensaje OTA. de acceder al array y de modificarlo de 
acuerdo con las instrucciones. 

Desde el punto de vista funcional, el sistema puede componerse de los 
siguientes elementos: 

10 - Una tarjeta GSM, UMTS o similar en la que hay un modulo (ya sea un 

API (Application Programming Interface - "interfaz para programar aplicaciones") o 
una aplicacion independiente) que se encarga de la gesti6n OTA de arrays. 

Un terminal que soporte SAT o USAT que soporte Data Download (cada 
vez vnAs modelos lo soportan -bastantes modelos de Siemens, Nokia. Samsung. 

15 Alcatel, etc.-) y/o que sea de clase "e". es decir que soporte los comandos de gesti6n 
de canales (actualmente hay pocos terminales que lo soporten pero su numero va 
aumentando). 

Un servidor OTA con los sistemas asociados. 
El m6dulo gestor de arrays presenta un interfaz adecuado para que pueda 
20 acceder a los arrays de las diferentes aplicaciones. 

Los medios de acceder al array pueden comprender: 

- medios de pedir una referencia del array a la aplicaci6n especificada; 

- medios de recibir la referencia solicitada; y 

- medios de acceder al array en base a dicha referencia. 

25 El modulo gestor de arrays de datos puede estar configurado para poder 

acceder a arrays de una pluralidad de aplicaciones. Por ejempio, el mddulo puede 
consistir en una aplicacibn independiente capaz de acceder a los arrays de una 
pluralidad de aplicaciones. 

Sin embargo, tambien existe la posibilidad de utilizar un modulo gestor 

30 especifico para cada aplicaci6n en la que se desea operar sobre datos en un array 
mediante acceso remote (OTA). Por ejempio, el m6dulo gestor puede formar parte de 
la aplicacibn concreta a cuyo array de datos se quiere acceder. por ejempio, estar 
constituido por un API (Application Programming Interface - "interfaz para programar 
aplicaciones"). 

35 Los medios de gestibn por acceso remote (OTA) pueden estar basados en la 
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norma GSM 03.48 o en la norma 3GPP 23.048. 

El dispositivo comprende preferiblemente un terminal que soporta SAT o USAT 
y que soporta Data Download y/o un terminal de clase "e" que soporta los cx)mandos 
SIM Toolkit para gesti6n de canales. 
5 Otro aspecto de la invencidn se refiere a un m6todo de gesti6n de datos en 

arrays de aplicaciones almacenadas en una tarjeta (por ejempio, en una tarjeta 
SIM/USIM) de un equipo de usuario de telefonfa mbvil, y que comprende los pesos de: 

recibir un mensaje de un servldor de acceso remoto (OTA), con al menos una 
instruccidn relative a al menos un dato en un array de una aplicaci6n almacenada en la 
10 tarjeta; 

analizar la instruccidn; 

en base a la Instruccidn, acceder al array; 

en base a la instruccidn, operar sobre dicho al menos un dato en el an^ay. 
El peso de acceder al array puede comprender los pesos de: 
15 - pedir una referenda del array a la aplicacidn; 
recibir dicha referenda; y 
acceder al array en base a dicha referenda. 

Preferiblemente, el mensaje se recibe en un terminal del equipo de usuario y se 
envia desde el terminal a la tarjeta, donde un modulo gestor de acceso remoto (OTA) 

20 en la tarjeta remite la instruccidn a un mddulo gestor de arrays de datos identificado en 
el mensaje. Preferiblemente, el mensaje es del tipo Data Download y se envfa a la 
tarjeta mediante el comando ENVELOPE. La instruccidn se puede remitir a un mddulo 
gestor de arrays de datos identificado mediante el campo TAR del mensaje. Tambidn 
existe la posibilidad de enviar el mensaje a la tarjeta a traves de un canal basado en el 

25 Bearer Independent Protocol (Protocolo Independiente de la Portadora). 

Un servicio que requiera la modificacidn de datos en una aplicacidn descargada 
de forma remota (o no) en la tarjeta puede emplear este sistema. El mddulo que 
gestiona los arrays debe ser capaz de identificar diferentes comandos para permitir 
una gestidn m&s flexible de los arrays. Es interesante emplear comandos que 

30 permitan, al menos: 

- Escribir 

- Leer 

A estos se pueden afiadir otros que faciiiten la gestidn como pueden ser 

- Borrar 
35 - Copiar 
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- Incrementar 

Una buena opcion es la de soportar los mismos comandos que se especifican 
en la norma GSM 11,11 y/o en la norma 3GPP 31.101 para gestidri de ficheros: 

- UPDATE BINARY 
5 - UPDATE RECORD 

- READ BINARY 

- READ RECORD 

- INCREASE 

Esto permite una gestidn flexible de los arrays con un minimo tamano de 

10 codigo. 

BREVE DESCRIPCI6N DE LOS DIBUJOS 
A cx>ntinuaci6n se pasa a describir de manera muy breve una serie de. dibujos 
que ayudan a comprender mejor la invencibn y que se relacionan expresamente con 
15 una realizacidn de dicha invenci6n que se presenta como un ejempio ilustrativo y no 
limitativo de 6sta. 

La figura 1 refleja, de forma esquemStica, algunos componentes de una tarjeta 
SIM/USIM de acuerdo con el estado de la t^cnica. 

La figura 2 refleja, de forma esquem^itica, algunos componentes de una tarjeta 
20 SIM/USIM que incluye un mddulo gestor de arrays de dates, de acuerdo con la 
invencibn. 

La figura 3 refleja, de forma esquemdtica, un sistema comprendiendo un 
dispositive y operando de acuerdo con la invenci6n. 



25 DESCR1PCI6N DE UNA REALIZACI6N PREFERIDA DE LA INVENCI6N 

De forma an^loga a la figura 1, la figura 2 refleja (una gran parte de los 
componentes pueden ser identicos a los de la figura 1 y han sido indicados con las 
mismas referencias num6ricas, para mayor claridad) una tarjeta SIM (o USIM) 1 que 
contiene un gestor de acceso remoto (gestor OTA) 2 que comprende un m6dulo gestor 

30 remoto de aplicaciones 2A y un modulo gestor remoto de ficheros 2F. La tarjeta 1 
incluye, adem^is, una primera aplicaci6n Toolkit 3A (SAT o USAT) y una segunda 
aplicacion Toolkit 4A (SAT o USAT). La primera aplicacibn Toolkit 3A est^ relacionada 
con (lee, escribe, manipula, etc.) datos 3D que se almacenan en un fichero 3F. Dicho 
fichero se ha establecido durante la personalizacibn de la tarjeta en la fdbrica (flecha 

35 "a" en la figura 2). La segunda aplicaci6n Toolkit 4A esXA relacionada con datos 4D 
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almacenados en un array que forma parte de la propia aplicacidn. 

La tarjeta 1 puede ser gestionada de forma remota mediante un sistema de 
acceso remoto (OTA); los mensajes OTA se reciben en el equipo de usuario y se 
transmiten a la tarjeta, en la que el gestor de acceso remoto 2 se hace cargo de 
5 realizar las operaciones oportunas. Mediante el mbdulo gestor remoto de aplicaciones 
2A se pueden cargar en la tarjeta 1 las aplicaciones 3A (flecha "b") y 4A (flecha "c") y, 
ya que el fichero 3F ha sido establecido en la fabrica durante la personalizacidn de la 
tarjeta, los datos 3D se pueden escribir, leer o manipular de forma remota (OTA) 
mediante el m6dulo gestor de ficheros (2F) (flecha "d"). 

10 Por otra parte y de acuerdo con la invencion, la tarjeta 1 contiene un m6dulo 

gestor de arrays de datos 5 que comprende: medios de recibir, mediante un mensaje 
de acceso remoto (OTA), al menos una instrucci6n de operacion sobre al menos un 
dato contenido en un array de una aplicacibn especificada (flecha "e" en la figura 2); 
medios de acceder a dicho array en funci6n de dicha instruccion; y medios de realizar 

15 al menos una operacion sobre dicho al menos un dato en dicho array, en funcibn de 
dicha instruccion. Por tanto, el modulo gestor de arrays de datos permite operar sobre 
los datos 4D en la segunda aplicacion Toolkit 4A, sin necesidad de borrar y re-escribir 
toda la aplicaci6n en la memoria de la tarjeta. 

La figura 3 refleja una realizaci6n preferida de la invencion, en la que el 

20 modulo gestor de arrays 5 consiste en una aplicacibn independiente, que puede 
implicar una ventaja f rente a la alternativa que consiste en que cada aplicaci6n 
gestione sus propios arrays. La ventaja consiste en que todos los mensajes que 
lleguen a la aplicacibn Gestor de Arrays (el modulo gestor de arrays 5) seran tratados 
como mensajes de gesti6n de arrays mientras que en la otra solucion, en la que cada 

25 aplicaci6n gestiona sus propios arrays, es necesario distinguir entre mensajes de 
gestidn de arrays y otro tipo de mensajes que pueda recibir la aplicacion para su 
operativa normal. 

La figura 3 refleja el siguiente proceso: 

El servidor de acceso remoto OTA 10 manda un mensaje M1 del tipo Data 
30 Download a un telefono m6vil. 

El terminal 20 del equipo de usuario del telefono mbvil recibe el mensaje y se lo 
manda a la tarjeta SIM/USIM 1 mediante el comando ENVELOPE M2, 

El gestor de acceso remoto (gestor OTA) 2 correspondiente de la tarjeta 1 
desempaqueta el mensaje (lo descifra, verifica el checksum, etc) y se lo manda a la 
35 aplicacibn (al m6dulo gestor de arrays de datos 5) que se indica en el campo TAR del 
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mensaje, mediante el mensaje M3 que comprende instrucciones relativas a la 
operacion que debe realizarse sobre los datos de la aplicacion 4A. 

El modulo gestor de arrays de datos 5 recibe las instrucciones (datos. 
comandos) donde se indica el array a modificar mediante el AID de la aplicacibn y el 
5 numero identificador del array que se asignan en tiempo de programaci6n. 

En el mddulo gestor de arrays de datos 5 se lleva a cabo el siguiente 
procedimiento, ilustrado en la figura 3: 

Desde "inicio" (SO) se pasa a un estado de espera de instrucciones S1. Una 
vez que se reciben las instrucciones, el modulo gestor analiza las instrucciones (paso 
10 S2) y, luego, efectua una llamada M4 a la aplicaci6n 4A solicitando una referenda al 
array (paso S3). 

La aplicacion 4A propietaria del array en cuesti6n envfa una referencia al array 
al modulo gestor de arrays de datos (5), mediante un mensaje M5. El m6dulo gestor 
de arrays de datos (5) recibe dicha referencia (paso S4). 
15 Seguidamente (paso S5), el Gestor de Arrays precede a escribir, leer, o lo que 

corresponda. 

Posteriormente (paso S6) manda un mensaje al Servidor OTA indicando el 
resultado de la operaci6n, preferiblemente, un mensaje corto (SM) utillzando el servicio 
de mensajes cortos (SMS) del sistema (M6+M7). 
20 Se pueden emplear los comandos soportados para gesti6n de ficheros 

indicados en las normas GSM 11.11 y 3GPP 31.101. 

Adicionalmente se puede emplear el comando SELECT por AID basado 
(aunque no ser6 igual porque no se espera recibir datos salientes) en la norma 3GPP 
31.101 para indicar la aplicacion propietaria del array y el comando SELECT para 
25 seleccionar el array. 

Los cbdigos de status pueden ser los mismos que se especifican en las normas 
correspondientes para los respectivos comandos. 

De esta forma el mensaje Data Download es una concatenaci6n de comandos 
como sigue: 

30 - SELECT por AID: para indicar la aplicacion 

- SELECT: para indicar el array 

- UPDATE BINARY, UPDATE RECORD, etc: para modificar el array. 

La respuesta serd la concatenaci6n de los c6digos de status, por ejempio, en 
caso correcto seria: 
35 - 90 00: Aplicacibn seleccionada correctamente 
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- 90 00: Array seleccionado correctamente 

- 90 00: Escritura correcta 

Los arrays pueden estar identificados para su seleccion por dos bytes como se 
indica a continuacidn: 

5 Byte 1: codifica la estructura de array. La codificaci6n es la misma que se 

define para los ficheros en la GSM 11.11, esto es: 

- 00 Binarlo 

- 01 Lineal Fijo 

- 03 Cfclico 

1 0 Byte 2: identifica el array. Los arrays seran dados de alta en la aplicaci6n con 

numeros secuenciales empezando por 00. 
Por ejempio: . 

Si el array 03 se pretende gestionar como lineal fijo, su identificador serd: 
01 03 

15 Y se seleccionar^ con el comando: 

AO A4 00 00 02 01 03 
El resultado de la seleccion serS: 
90 00 

A lo largo de la presente descripcibn y reivindicaciones la palabra "comprende" 
20 y variaciones de la misma, como "comprendiendo", no pretende excluir otros pasos o 
componentes. 



25 



30 
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REIVINDICACIONES 

1. - Un dispositivo de telefonfa mbvil, que comprende: 

un dispositivo de almacenaje (1) que comprende medios para almacenar, al 
5 menos, una aplicaci6n (3A, 4A); 

medios de gesti6n por acceso remoto (OTA) del dispositivo de almacenaje en 
base a recepcibn de mensajes de acceso remoto (OTA) por telefonia mdvil; 
caracterizado porque 
comprende ademas 

10 al menos un m6dulo gestor de arrays (5) de datos de, al menos, una aplicaci6n 

almacenada en el dispositivo de almacenaje, comprendiendo dicho mbdulo gestor de 
arrays de datos: 

- medios de recibir, mediante un mensaje de acceso remoto (OTA), al menos 
una instrucci6n de operaci6n sobre al menos un dato (4D) contenido en un array de 

15 una aplicaci6n (4A) especificada; 

- medios de acceder a dicho array en funcibn de dicha instrucci6n; y 

- medios de realizar al menos una operacibn sobre dicho al menos un dato (4D) 
en dicho array, en funcibn de dicha instruccibn. 

2. - Un dispositivo segun cualquiera de las reivindicaciones anteriores, 
20 caracterizado porque los medios de acceder a dicho array comprenden: 

- medios de pedir una referenda del array a la aplicaci6n especificada (S3); 

- medios de recibir la referenda solicitada (S4); y 

- medios de acceder al array en base a dicha referencia (S5). 

3. - Un dispositivo de acuerdo con cualquiera de las reivindicaciones 1 y 2, 
25 caracterizado porque la aplicacion es una aplicad6n SAT o USAT. 

4. - Un dispositivo segun cualquiera de las reivindicaciones anteriores, 
caracterizado porque el dispositivo de almacenaje (1) es una tarjeta chip (ICC) con un 
modulo de identificaci6n de usuario (SIM/USIM). 

5. - Un dispositivo segun cualquiera de las reivindicaciones anteriores, 
30 caracterizado porque el m6dulo gestor de arrays de datos (5) est6 configurado para 

poder acceder a arrays de una pluralidad de aplicaciones. 

6. - Un dispositivo segun cualquiera de las reivindicaciones 1-4, caracterizado 
porque el modulo gestor de arrays de datos forma parte de la aplicacion concrete a 
cuyo array de datos debe poder acceder. 

35 7.- Un dispositivo segun la reivindicacibn anterior, caracterizado porque el m6dulo 



wo 2004/014093 




:T/£S2003/000400 



-13- 



gestor de arrays de datos es un interfaz para programas de aplicacibn (API). 
8.- Un dispositive segun cualquiera de las reivindicaciones anteriores, 
caracterizado porque los medios de gestion por acceso remoto est^n basados en la 
norma GSM 03.48 o en la norma 3GPP 23.048. 
5 9.- Un dispositivo segun cualquiera de las reivindicaciones anteriores, 
caracterizado porque comprende un terminal (20) que soporta SAT o USAT y que 
soporta Data Download y/o un terminal de clase "e" que soporta los comandos SIM 
Toolkit para gestion de canales. 

10. - Un m6todo de gestidn de datos en arrays de aplicaciones almacenadas en una 
10 tarjeta (1) de un equipo de usuario de telefonia m6vil, caracterizado porque comprende 

los pasos de: 

recibir un mensaje (Ml) de un servidor (10) de acceso remoto (OTA), con al 
menos una instruccion relativa a al menos un dato en un array de una aplicacion (4A) 
almacenada en la tarjeta; 
15 - analizar la instrucci6n (S2); 

en base a la instruccibn, acceder al array (S5); 

en base a la instrucci6n, operar (S5) sobre dicho al menos un dato en el array. 

11. - Un m6todo segun la reivindicacibn 10, caracterizado porque el paso de acceder 
al array comprende los pasos de: 

20 - pedir una referenda del array a la aplicacion (S3); 
recibir dicha referenda (S4); y 
acceder al array en base a dicha referencia (S5). 

12. - Un metodo segiin cualquiera de las reivindicaciones 10 y 11, caracterizado 
porque 

25 - el mensaje (Ml) se recibe en un terminal (20) del equipo de usuario; 
el mensaje se envia desde el terminal a la tarjeta (1); 

un modulo gestor de acceso remoto (OTA) (2) en la tarjeta remite la instrucci6n 
(M3) a un modulo gestor de arrays de datos (5) identificado en el mensaje. 

13. - Un metodo segun la reivindicaci6n 12, caracterizado porque el mensaje (Ml) es 
30 del tipo Data Download. 

14. - Un m6todo segun la reivindicacibn 13, caracterizado porque el mensaje se 
envia a la tarjeta (1) mediante el comando ENVELOPE (M2). 

15. - Un m6todo segun la reivindicacibn 12, caracterizado porque el mensaje (Ml) se 
envia a la tarjeta a trav^s de un canal basado en el Bearer Independent Protocol 

35 (Protocol© Independiente de la Portadora). 
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16.- Un m^todo segun cualquiera de las reivindicaciones 14 y 1.5, caracterizado 
porque la instruccion se remite a un mbdulo gestor de arrays de datos (5) Identificado 
mediante el campo TAR del mensaje. 



